Change summary to:

/// Represents a 24bit color. Supports translating to 4bit (Windows) and 8bit (Linux) colors.

Please apply correct source code formatting to all files in this PR (hit Ctrl-K-D in VS).

Auto format applied.

I'm confused as to why this class is needed? Why not just put this into Attribute and make it so true color is the default/assumed, supporting non-truecolor as a fallback?

When would someone use this class?

As describe before we need to decide which color escape sequence we should use. To keep backward compatibility i just introduced a new TrueColorAttribute class which holds the rgb values, like in the other PR.

This method has also the advantage that you only need to create new color escape sequences when the instance reference changes. However i can not evaluate if this has further side effects.

Furthermore there is no easy way to merge basic color and truecolor attribute class because any platform defines its own basic color range. The later must be unified first.

Would it be possible to write a mapping algorithm for true color to Console Color (and vice versa)?

An approximation would be fine, I'm guessing someone has already done this elsewhere.

If we could translate between the two then we could just add the properties to Attribute and add a new true color constructor. So the pseudocode would be something like:

public class Attribute
{
	public int RedForeground { get; }
	public int GreenForeground { get; }
	public int BlueForeground { get; }

	public int RedBackground { get; }
	public int GreenBackground { get; }
	public int BlueBackground { get; }

	public Color Foreground { get; }
	public Color Background { get; }

	public Attribute (Color foreground, Color background)
	{
		Foreground = foreground;
		Background = background;

		var m = MapToTrueColor (foreground);
		RedForeground = m [0];
		GreenForeground = m [1];
		BlueForeground = m [2];

		m = MapToTrueColor(background);
		RedBackground = m[0];
		GreenBackground = m[1];
		BlueBackground = m[2];
	}

	public Attribute (int redForeground, int greenForeground, int blueForeground, int redBackground, int greenBackground, int blueBackground)
	{
		RedForeground = redForeground;
		GreenForeground = greenForeground;
		BlueForeground = blueForeground;


		RedBackground = redBackground;
		GreenBackground = greenBackground;
		BlueBackground = blueBackground;

		Foreground = MapToBasicColor (redForeground,greenForeground,blueForeground);			

		Background = MapToBasicColor (redBackground,greenBackground,blueBackground);			
	}

    [...]
}

That would allow clients to mix and match true color whenever they wanted. And even have an app that supports true color but falls back on basic colors when deployed to an older machine (with zero effort on the API consumers behalf)?

EDIT: Just realized Attribute describes both foreground and background so have updated the pseudocode.

Yeah, something like that could work. Maybe we can track the index by the lifetime of the Attribute class and use a database approach to select a free index by incrementing a static next-index value.

Apparently this is the RGB breakdown. I might pull your branch and see if a 'transparent' and backwards compatible approach can be adopted following this approach.

@veeman I've started working on this approach in https://github.com/tznind/gui.cs/tree/true-color

Once its ready (and assuming its viable) I will open a PR to your branch.

This whole switch statement scares me. So much brute-force code! It makes me wonder if there's a way of re-factoring it as part of this PR to use reflection or something to radically simplify it?

I'm confused as to why there's ALSO a method in CursesDriver.cs called CanColorTermTrueColor. Why not just have CursesDriver implement an override of this method?

I think this method should be named SupportsTrueColor for tersness.

This must be abstract in the ConsoleDriver.cs to force to be implemented in all drivers.

The CursesDriver currently does not implement the TrueCollorAttribute feature.
On *unix, there is no easy way to determinate if the current terminal supports color output.
Despite ncruses provides a check for color support, it tells only if the library is compiled with color output support.

The unofficial community way is to check the environment variable COLORTERM for some magic values. This does the static CursesDriver.CanColorTermTrueColor function. This variable is also set under WSL, so i just retrive this information in the NetDriver.

The virtual property SupportsTrueColorOutput tells if the used driver and the used terminal environment supports color output.

The property UseTrueColor is used to decide which mode should be used. If SupportsTrueColorOutput is set then UseTrueColor is also set, but can be uesed to enter baisc color rendering.